Distributed denial of service (DDoS) attacks are now a major threat to all financial institutions, e-commerce businesses, as well as governments. DDoS attacks can take down stock exchanges, voting sites, as well as other critical online infrastructure. Many organizations are investing larger sums of their capital to mitigate this devastating attack vector.
Though currently most of a company's budget is applied to the mitigation systems themselves, validating the DDoS mitigation systems deployed in an organization is becoming a necessity. Similar to the way in the 1990's that firewalls were deployed, next IPS device, and WAF devices, organizations then wanted to verify these systems actually do what the systems were relied upon to do, that is protect their network from being hacked into. The phrases “pentesting” (penetration test) and “vulnerability scanning” became synonymous with every organization's cyber security program for protecting their network against malicious infiltration.
The same logic applies to current DDoS simulation testing. Organizations like stock exchanges, banks, governments etc. cannot afford to have downtime without having significant financial and public relations damage. Companies should have ongoing DDoS tests run against the company's environment to ensure security. However, because of time constraints involved with current testing methodologies only a fraction of tests are performed with disruptive testing.
Currently, conventional “DDoS testing systems” and methodologies offered commercially as a service or by security consultants are disruptive to the IT infrastructure of the organization targeted for the DDoS test simulation. This requires that a maintenance period usually needs to be organized within the company or as a substitute the DDoS simulation is performed against a staging environment (in order to prevent any downtime), which is often not an exact replica of the production environment. This also means conventional tests are more a “one-off” DDoS test simulation. Even in companies who do conventional DDoS testing diligently, they do not perform such testing more than once a quarter because of the associated logistics setting up maintenance periods for the testing.
The drawback of a one-off disruptive DDoS test every quarter or a couple of times a year, is that besides the fact that a maintenance window is needed and will likely have service downtime, the DDoS test only verifies the system for that exact point in time, leaving large gaps in an organizations cyber security posture.
Currently, DDoS tests that validate DDoS mitigation systems, or the service reliability of an organization with regards to DDoS attacks, are done with systems, platforms or tools that launch large volumes of traffic or specific application layer traffic from one or more nodes or agents from one or more locations around the world (mainly on the internet) against the organization receiving the DDoS test simulation. The attacks are designed to disrupt and attempt to affect the organization's service availability. The DDoS test traffic aims to disrupt service availability or see the upper limits of what the organization can withstand in terms of their deployed IT infrastructure. Current tests verify how many “packets per second”, “connections per second”, “megabits per second” or malicious quantities of traffic the organization can withstand until service availability is affected. This type of conventional testing is extremely disruptive to ongoing service availability. This disruption deters some organizations from performing such tests. However, this testing may be required by regulations and/or/law.
In disruptive style DDoS tests, more than one test (and therefore maintenance period) is necessary because configuration issues may have been overlooked or obvious flaws with current mitigation systems unknown. This causes the infrastructure to be negatively affected during the test at which point all IT staff prefer to bring the test to an end (especially if working on production systems) until the causes are better understood and assumed reasons for the infrastructure failure resolved. Another test is run and this iterative process repeated. Had these configuration issues and flaws been known before hand, all the disruption to the production environment and internal staff logistics of the organization being tested could have been greatly reduced. Also, significantly more attack vectors can be verified during disruptive DDoS testing if you previously have run the non-disruptive DDoS testing proposed.
Another clear issue with disruptive DDoS testing is the fact that only a limited amount of tests can be run during a specific maintenance window, for example per hour up to a dozen DDoS tests may be able to be run, at best. This means that to test hundreds of DDoS scenarios against potentially thousands of targets would take many thousands of cumulative man-hours for the organization. As a result, currently only a small subset of potential DDoS attack vectors are checked and verified against a small subset of targets. The reason being is resource allocation for staff and budget for testing on that level is not realistic for most organizations. This approach unfortunately in reality weakens the organization's resilience to a determined and sustained DDoS attack. This was clearly demonstrated during recent attacks on US banks. Recent attacks showed major flaws in defenses of even the most well funded and supposedly best-protected organizations. There are still many flaws that remain in the same organizations targeted previously and these organizations would benefit from ironing out current infrastructure and mitigation weaknesses with regards to DDoS attacks. Though in practice to refine their DDoS mitigation strategy is an increasingly complex and costly task.
With DDoS attacks becoming a more and more common cyber security attack vector, organizations want to make sure that services (CPE/Scrubbing) and strategies deployed are able to withstand an actual DDoS attack. The main objective of a DDoS attack is to take down the targeted organization, but can also lead to more targeted attacks for data theft. DDoS attacks can kill stateful devices which normally protect otherwise vulnerable services (for example, firewalls or WAF's).